(1) Field of the Invention
The present invention relates to distributed information protection and network security and, more particularly, to an enhanced method for secure single-packet remote authorization using a daemon that passively monitors a network for a specially constructed encrypted packet and anonymously accepts or rejects subsequent connection attempts based on the characteristics of said packet.
(2) Description of Prior Art
Network technology is invaluable for sharing resources. However, connecting a computer or network to the Internet is a risky proposition. There is a high probability that eventually, someone will gain unauthorized access. To exploit a server-side application vulnerability, an intruder needs to gain access to an open port leading into the system, or trick the host system into opening one (through shellcode that exploits a software vulnerability and opens a backdoor into the system for example). This requires a combination of the host system's unique IP (Internet protocol) address, and the ability to talk to the server's TCP (Transmission Protocol) or UDP (User Datagram Protocol) stack and corresponding ports that serve as the door into the host system.
Firewalls help to prevent the ability of attackers to exploit software vulnerabilities through the use of port and protocol filtering to minimize server access from arbitrary IP addresses, and also through the use of NAT (network address translation) for protected internal hosts. Unfortunately, conventional firewalls operate under a fixed ruleset which, if predicted or examined through various scanning methods, can offer little protection for vulnerable services. Consequently, a variety of more robust authorization techniques have evolved to increase security.
For example, U.S. Patent Application Nos. 20050182968 and 20030140248 both by Izatt et al. show an “Intelligent firewall” that analyzes incoming packets to determine whether or not they are acceptable to forward on to a destination in the network. If the packet is not acceptable, access to the network is denied and the packet is dropped with no denial of access message being sent to the source of the packet. As a result, there is no detectable response to the sender of denied access from the firewall.
United States Patent Application 20050240994 by Burcham published Oct. 27, 2005 shows a method for maintaining network access and security that uses a perimeter client and a perimeter server.
“Port knocking” is a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports. Once a correct sequence of connection attempts is received the firewall rules are dynamically changed to allow the computer that sent the connection attempts to connect over specified port(s). Port knocking is typically implemented by a daemon (a computer program that rims in the background) that watches the firewall log file for connection attempts and that modifies the firewall configuration accordingly. The port knock sequence itself is a secret handshake comprising any number of TCP, UDP packets to numbered ports on the host system. The complexity of the knock can be anything from a simple ordered list of ports to a complex time-dependent, source-IP-based encrypted string. The portknock daemon listens for knocks on certain ports (either via the firewall log or by packet capture) and allows access accordingly. When the concept of port knocking was announced in 2003 (Krzywinski, M., Port Knocking: Network Authentication Across Closed Ports, SysAdmin Magazine 12: 12-17; 2003), many competing implementations were rapidly developed. There are now over 30 different software projects dedicated to various implementations of port knocking. The two most important characteristics of port knocking in terms of enhancing security are: 1) the passive communication of authentication information from a remote system to the host system, with no return of data (anyone who casually scans the target system will not be able to tell that there is any server listening on the ports protected by the knock server); and 2) the server side use of a packet filter to intercept all attempts to connect with the server that are not associated with a valid port, knocking sequence. Consequently, even if an attacker possesses the host system's IP address, TCP and UDP ports that serve as the door to the host system are completely inaccessible without first issuing a valid knock sequence.
The present inventor has implemented an open-source daemon called fwknop (Firewall Knock Operator), which supports an entirely new mechanism for network authentication and authorization called Single Packet Authorization that requires only a single encrypted packet in order to gain access to protected services. This new mechanism offers many advantages over both shared and encrypted port knock sequences as discussed below.
Unfortunately, port knocking is not designed to provide bullet-proof security, and, indeed, replay attacks can easily be leveraged against a port knock server in an effort to masquerade as a legitimate client. Moreover, in port knocking schemes the communication of information within packet headers as opposed to the packet payload severely limits the amount of data that can effectively be transferred. The port fields of the TCP and UDP headers are 16 bits wide, so only two bytes of information can be transferred per packet in a traditional port knock sequence. This assumes that other fields within the packet header are not also made significant in terms of the knock sequence, but any conceivable implementation would not be able to transmit nearly as much information as a protocol that makes use of payload data. If only two bytes of information were all that were required to communicate the desired access to a portknock daemon then this would not be a significant issue, but it is not enough to simply create a mapping between a knock sequence (however short) and opening a port. An encryption algorithm can help, but even a symmetric block cipher with a reasonable key size of, say, 128 bits forces at least 8 packets to be sent at two bytes per packet. As soon as multiple packets become involved, we need to try to ensure that the packets arrive in order. This implies that a time delay is added between each successive packet in the knock sequence. Simply blasting the packets onto the network as quickly as possible might result in out of order delivery by the time the packets reach their intended target. Because the knock server is strictly passively monitoring packets and consequently has no notion of a packet acknowledgment scheme (such as built into the Transmission Control Protocol), a reasonable time delay is on the order of about a half second. Given a minimum of 8 packets to send, we are up to four seconds just to communicate the knock sequence. In addition, if there were ever a need to send more information, say on the order of 100 bytes, the time to send would be longer than most people would be willing to wait.
Unfortunately, under current port-knocking schemes, a consequence of sending multiple packets in a slow sequence is that it becomes trivial for an attacker to break any sequence as it is being sent by the port knocking client. All the attacker needs to do is to spoof a duplicate packet from the source address of the client as a knock while the sequence is in progress. This duplicate packet would be interpreted by the knock server as part of the sequence, and hence breaking the original sequence. There is existing software (programs like hping available at http://www.hping.org) that makes it exceedingly easy to spoof IP packets from arbitrary IP addresses. It is not enough just to encrypt knock sequences as encryption can be deciphered as well.
There are no traditional port knocking methods that elegantly prevent replay attacks, though some make it difficult (such as altering knock sequences based upon time, iterating a hashing function as in the S/KEY system, or even manually changing the agreed upon encryption key for each successful knock sequence). However, each of these known methods requires keeping state at both the client and the server, and does not scale well once lots of users become involved. However, in applicant's co-pending application Ser. No. 11/726,518 filed 22 Mar. 2007 he describes an authentication and authorization scheme employing Single Packet Authorization that does not suffer from this type of easy injection attack. This approach relies on a single packet authorization (SPA) server on a host system to passively monitor the network for connection attempts and an SPA client on a client system that is responsible for generating the appropriately encrypted SPA packet in order to gain access to services on the host. The SPA host server anonymously accepts or rejects those attempts depending on whether a valid SPA packet is detected. A particular packet format is sent from the SPA client to the SPA host to gain access. The format is encrypted and non-replayable by virtue of 16 bytes of random data in every message, and an MD5 sum that is a hash function of the random data (made via any known hashing function). The SPA server stores the MD5 sum of every valid SPA packet that it monitors. This makes it possible for the SPA server to know which messages have been sent before. The SPA Server does not honor those that are duplicates of previous messages, but rather flags any duplicate access attempts using the same MD5 hash as a previously monitored packet, in which case the SPA server treats the packet as being generated by a malicious attempt to replay the original packet and rejects it. The foregoing software method effectively prevents attackers from replaying captured messages against an SPA host server in a client-server architecture, but is unsuited for use in a Cloud Computing network when NAT access is needed through the SPA server system to a separate internal Cloud system on non-routable IP space. Such access is advantageous in some cases in Cloud computing networks that follow the Infrastructure as a Service (IaaS) model and that only enable limited rentable IP addresses to be bound to cloud-resident hosts.
The present application discloses an enhanced version of Single Packet Authorization that is meant to provide transparent access to software services that reside on cloud-based servers, other than the host system where the SPA server itself is running.